1. Field of the Invention
This invention generally relates to virtual machines which are guest machines of real (host) machines. In particular, this invention relates to adjunct virtual machines that either serve the virtual (base) machines or that form a multi-processing configuration.
2. Prior Art
When a virtual guest logs on to either a real (host) uniprocessor (UP) system or a real (host) multi-processor (MP) system, a virtual machine definition control block (guest VMDBK) is created in a region of host storage. This area contains all of the device information and control blocks necessary to define a guest. The pointer for this guest VMDBK is found in the SYSGEN common area in the reserved storage region, i.e. within the host nucleus. At any point during the operation of the data processing system, the running guest VMDBK will be one of several types, e.g. IBM System/370-XA or IBM System/370. Its type is assigned when the VMDBK is created and may be altered by definition commands. The address of the virtual CPU which the VMDBK represents will be contained in a chain of VMDBKs called the global cyclic list (VMDCYCLE) if more than one guest logs on to the system. A guest VMDBK includes: (1) the guest state descriptor (SD) which describes the virtual guest to the host system, (1a) a description of the guest's mode (or type), i.e. System/370, (1b) the guest's storage size, (1c) the guest program status word (PSW), (1d) contents of the guest's control registers 0 through 15, (2) the contents of the guest's general purpose registers 0 through 15, and (3) the guest's floating point registers 0 through 6.
U.S. Pat. No. 4,456,954 issusd to Bullions, III et al. and assigned to the same assignee as the present application describes a start interpretive execution (SIE) instruction which enables a virtual (guest) uniprocessor system to be emulated in a real UP or in a real MP system. SIE consists of an operation code and an operand address of a control block in real main storage (MS). This control block is the state descriptor (SD) and is included with the guest VMDBK as stated above. The SD contains a plurality of fields which receive data that define the state of a virtual system, i.e. a virtual CPU with a virtual storage, and certain states for controlling how the virtual system is to operate on the real (host) system. Therefore, one SD, existing in real main storage, defines a virtual UP system, i.e. one virtual guest. More than one SD defines a plurality of virtual UP systems, i.e. a plurality of guests. The plurality of virtual guests are operated on when the real (host) system serially executes SIE instructions each specifying a virtual guest by its corresponding SD. A process called invoking SIE occurs whenever a SIE instruction is executed in a host program's instruction stream. This process provides for the guest to be emulated by enabling microcode and hardware in the real CPU to support the virtual guest invoked by the SIE instruction. After the SIE instruction is invoked, the guest program begins execution for the virtual guest defined by the SD which is pointed to by the SIE instruction.
Virtual MP systems may also be provided in a real MP system which includes a plurality of real CPUs which are tightly coupled to a common real main storage. In such real MP systems, the plurality of virtual MP systems is defined by a respective plurality of VMDBKs in real main storage in the same manner as described above for a real UP system. Thus, each of the plurality of VMDBKs defines a different virtual guest in the real MP system. Any one or more of the plurality of real CPUs in an MP system may, at any time, be in emulation mode in which a guest program executes under a respective SIE instruction. In other words, a plurality of virtual MP systems, identified by different VMDBKs in the real MP main storage, can execute program simultaneously.
A further description of interpretive execution is found in an article by P. H. Gum in the IBM Journal of Research and Development, Volume 27, Number 6, November 1983, entitled "System/370 Extended Architecture: Facilities for Virtual Machines". Additional pertinent information is found in co-pending U.S. patent application Ser. Nos. 561,614 and 635,388 which have the same assignee as the present application.
Pertinent art is also described in an article by G. D. Bagley entitled "The Scout--An Extended Virtual Machine", which was referenced in, Computer, IEEE, Vol. 9, No. 2, February 1976, pages 38-42. In the Scout machine, a portion of the guest real storage, having a primary guest operating system, is reserved for a special (secondary) guest operating system which is capable of modifying the primary guest operating system. A number of problems made the Scout machine concept generally unacceptable. For example, two consoles are needed to avoid conflicts between the guest operating systems, the special guest operating system is modified in order to handle page zero and I/O interrupts are interpreted so that they are reflected to the correct operating system. Furthermore, there is loss of real storage from the primary to the secondary guest operating system.
An object of this invention is to make available to the user all other system control program console functions during the execution of a system control program console function.
An object of this invention is to create a prototype adjunct virtual machine CPU that provides a service to a base virtual machine CPU and that can be used as a model for every base virtual machine that requires that service.
A further object of this invention is to define the architecture of the adjunct virtual machine CPU in a single directory for creating a prototype adjunct virtual machine CPU only once for use by any number of virtual systems.
An object of this invention is to utilize one console for both the virtual system and its adjunct virtual machines.
Another object of this invention is to utilize adjunct virtual machines in either a guest service or a guest multiprocessor configuration.
A further object of this invention is to create adjunct virtual machines that provide services for either a V=V or a V=R guest.
A processor which serves another processor (or several processors) is known in the art. From the point of view of hardware, a service processor, e.g. the IBM 3082, provides service and diagnostic functions for a real (main) UP system, e.g. the IBM 3083, or for a real (main) MP system, e.g. the IBM 3081. (The IBM 3081 includes two integrated central processing units, each having equal access to central storage and two sets of channels that link it with input/output (I/O) devices.) The service processor shares the storage of the UP or MP systems which it services.
A processor which serves another processor is shown by the data processing system of FIG. 1. In particular, the data processing system includes an MP system having first and second (real) CPUs (CP0, CP1), system controller (SC), main storage (MS) and external data controller (EXDC). Each CPU includes a buffer control element (BCE), instruction element (IE), execution element (EE) and control storage element (CSE). During system initialization, the microcode is loaded into a buffer and into a designated (system) area in MS. The CSE supplies the microcode controls to the IE. The IE is that portion of the CPU that, under microcode control, receives and interprets instructions from MS and dispatches the operands to the appropriate executing area. Storage operands are fetched by the IE from the BCE. The BCE controls the data path between the CPU and the SC, and the data paths within the CPU. The EE processes instructions under hardware control. The EXDC provides the hardware and microcode controls to support I/O channels for control units and I/O devices.
Also included in the data processing system of FIG. 1 is a (real) service processor (SP) which provides and performs functions for the MP system. For example, the SP provides control-unit functions for substantially all consoles, and provides for the monitoring and supervising of all operations in the MP system. The service processor has access to the real CPUs of the MP system and MS as represented by the dotted lines in FIG. 1.
An object of this invention is to utilize adjunct virtual service machines that do not share the storage of the main UP or MP configuration.